1. DEPLOYMENT SCENARIOS

In SharePoint 2013, the physical location of the SharePoint server farm plays an important role in the development pattern you should follow and the options available to you. As the developer the first question you should ask yourself is which deployment scenario you are building your custom solutions for. SharePoint 2013 offers four different types of deployment scenarios: on-premise, Office 365, hosted, and hybrid deployment.

On-Premise Deployment

In this deployment scenario, SharePoint sits behind the corporate firewall and is maintained by your IT department. Just like previous versions of SharePoint, this scenario offers you a lot of flexibility for development options and the tools you use.

Office 365 Deployment

In this deployment scenario, your SharePoint farm is kept in Office 365 and managed by Microsoft. You can use all the development options and tools available in on-premise deployment (scenario 1), except for running server-side code in apps.

Hosted Deployment

Similar to an Office 365 deployment scenario, in hosted deployments your SharePoint server farm is installed and hosted by third-party providers, which may or may not be Microsoft. For example, you can deploy your fully virtualized SharePoint farm to CloudShare, Amazon EC2, or on Windows Azure virtual machines owned by Microsoft. Depending on the vendor hosting your SharePoint farm, your mileage may vary, and your development pattern and options could differ. Some third-party hosting providers offer your own dedicated cloud without sharing it with anyone else, which gives you more options.

Hybrid Deployment

This is the only deployment scenario that spans across your corporate firewall and the cloud. In this scenario, part of the installation is managed internally by corporate IT, and some applications are deployed to another SharePoint farm in the cloud in Office 365 or a third-party hosting provider.

2. PACKAGING SCENARIOS

Where and how SharePoint is installed and deployed dictates your options in how you can package and deploy your custom code. There are three deployment options: full-trust farm solutions, partial-trust farm solutions, and apps.

Full-Trust Farm Solution

Farm solutions were introduced in SharePoint 2007, and they are only available in on-premise deployments in SharePoint 2013 and some dedicated cloud-based deployments. These types of solutions can contain customizations used across an entire farm. Custom code in full-trust solutions is deployed to the SharePoint web application’s \BIN directory or global assembly cache (GAC). Code can be secured using .NET’s Code Access Security (CAS) but typically is run in full trust. These types of solutions are added to the farm in SharePoint by an IT pro with console access and deployed by someone with farm administrator rights.

Partial-Trust Sandboxed Solution

This option, introduced in SharePoint 2010, is available in all types of deployment scenarios. Sandboxed solutions are available to all sites across an entire site collection where they were deployed. These types of solutions can be uploaded and deployed by site collection administrators.

Apps for SharePoint

There is a new way of packaging and deploying your code in SharePoint 2013. This approach is heavily dependent on the notion of isolation and small widgets called apps. If you own a smartphone, you are already familiar with the notion of apps. Apps are built and deployed to target specific business needs, and they are transactional in nature. Apps for SharePoint are different than those built for smartphones because they do not live in SharePoint, and the actual execution doesn’t happen in SharePoint. Apps execute in the browser client or on a remote web server; they’re granted permission into SharePoint sites via OAuth and communicate over the newly improved SharePoint 2013 CSOM APIs.

3. THE PROGRAMMING MODEL

SharePoint 2013 ships with one fundamental difference in its programming model. In the new programming model, the emphasis is more on cloud computing, standard web technologies such as JavaScript and HTML, and remote access. All new changes are aligned with the company’s overall strategy of “Everything has to be available in the cloud.”

Before you dive too much into the new changes, first go back a few years in time to refresh your memory about the evolution of customization and coding in SharePoint.

The Evolution of SharePoint Programming

At a high level, Figure 1 shows the programming models in SharePoint 2007 and 2010.

FIGURE 1

In SharePoint 2007, your custom code either ran server side in SharePoint or hosted in your own service layer (IIS, Apache, others) working with some areas of the SharePoint object model remotely via built-in web services located in the _vti_bin folder (%COMMONPROGRAMFILES%\Microsoft Shared\web server extensions\12\ISAPI). SharePoint 2007 had a limited client-side object model, which was implemented in the Core.js JavaScript file (which was OWS.js in Windows SharePoint Services 2003). The JavaScript file was referenced from most SharePoint pages and contained limited logic necessary to handle various events on the client without having to modify the out-of-the-box Core.js file. For example, Core.js provided a hook through which additional menu items could be shown in the context menu (ECB), as demonstrated in the following code snippet:

function AddDocLibMenuItems(m, ctx)
{
    if (typeof(Custom_AddDocLibMenuItems) != "undefined") 
    {
        if (Custom_AddDocLibMenuItems(m, ctx)) return;
    }
    . . . // build the rest of OOTB ECB menu items
 }

By using SharePoint Designer (or Microsoft Office FrontPage in Windows SharePoint Services 2003), developers injected their implementation of Custom_AddDocLibMenuItems function into a SharePoint page, or they could use the Content Editor Web Part (CEWP) to inject the custom JavaScript function into web part pages. Either way, Core.js was calling its function in run time. The problem with this extensibility model was that it was limited and not flexible. For example, if for any reason Core.js is not loaded, your custom function won’t work either.

In SharePoint 2010, the Client Side Object Model (CSOM) was substantially improved to address the challenges with client-side programming in the earlier versions of SharePoint. SharePoint 2010 CSOM fundamentally was a Windows Communication Foundation (WCF) service called Client.svc and shipped with three different proxies to enable Silverlight, JavaScript, and .NET managed clients (C# or VB.NET) to call into the product remotely. The following code snippet shows how a developer can use the supported proxy for JavaScript (sp.js) to execute an asynchronous query against CSOM in SharePoint 2010:

           ExecuteOrDelayUntilScriptLoaded(GetTitle, "sp.js");
// Code omitted for brevity
function GetTitle() {
    //Retrieve current client context
    context = SP.ClientContext.get_current();
 
    //Load the site 
    site = context.get_web();
    context.load(site);
 
    //Execute asynchronously with callbacks for successful or failed calls
    context.executeQueryAsync(onQuerySucceeded, onQueryFailed);
  }

Challenges with CSOM in SharePoint 2010

Developers had two major issues using CSOM in SharePoint 2010.

First, direct calls to Client.svc were not supported, and all the calls had to go through the supported entry points (for example, sp.js). Proxies were only available for .NET managed, Silverlight, and JavaScript clients, so platforms or devices that didn’t understand either of these technologies could not call SharePoint remotely.

Second, CSOM covered only APIs in the Microsoft.SharePoint.dll and limited workloads in the product. To overcome this limitation, developers had no option but to rely on ListData.svc, jQuery against built-in ASMX Web Services, or server-side code to get better coverage of the product’s object model.

Developers preferred to use CSOM from managed code (for example, C# and VB.NET) more than from JavaScript. That’s because they could program against strongly typed objects and experience compile-time type IntelliSense and easier debugging. JavaScript development against CSOM was not easy. The code was harder to write and debug because the calls had to be asynchronous with no compile-time type checking and IntelliSense.

The next section discusses why you should think twice before writing server-side code in SharePoint 2013.

Challenges with Server-Side Code

Microsoft has several reasons to push client-side programming and remote access in SharePoint 2013. The most candid reason is that the root cause of most SharePoint performance and security issues has been the server-side code included in farm or sandboxed solutions. Now play the role of devil’s advocate for a second. If you were a software company building a platform for others to host their products in it, and potentially make money, how would you feel if someone writes a web part that brings your baby to its knees? How would you feel if someone says your product is slow, but in reality it’s someone else’s code or misconfiguration that has made you look bad?

Another problem with the SharePoint server-side object model is that it’s difficult to learn and it lacks cross-technology interoperability with other non-Microsoft technologies. In many cases, SharePoint had problems catching up with the newer Microsoft technologies, too. How many times as a developer have you suffered from the SharePoint object model being tightly coupled with a specific version of the .NET Framework or Windows Workflow Foundation? How many times did you wish that your PHP buddy could give you a hand in your SharePoint projects?

The new programming model in SharePoint 2013 introduces a much quicker ramp-up time for developers who may not know SharePoint APIs and enables those developers who use other technologies to be productive. Now, you can build solutions that are a lot more technology-agnostic and loosely coupled from the product. This means you can choose your preferred scripting language (PHP, JavaScript, LAMP, and so on) or any version of ASP.NET (ASP.NET Web Forms, MVC, and Web Pages), build apps for SharePoint, and use remote calls to accomplish various tasks that were previously only possible through the server-side object model.

In addition to perception and tactical challenges, server-side solutions often had lots to deploy and required direct access to the server. This is fine in on-premise deployment scenarios, but it is not an option in the cloud unless you have your own private server. You could get around this limitation by using sandboxed solutions, but sandboxed solutions had their own issues. First, there are limited sets of operations you can do in the sandboxed because only a subset of the server-side SharePoint APIs is available in sandboxed solutions. Sandboxed solutions can’t execute for longer than 30 seconds, and they cannot exceed a certain amount of resource usage per day. In addition, server-side code cannot make calls/requests to externally hosted web services. However, developers can use client-side based solutions (using JavaScript or Silverlight) to call external services and even make cross-domain calls using techniques such as HTTP post messages.

Another common developer challenge pre-SharePoint 2013 was solution upgrading. WSP versioning, feature upgrading, assembly versioning, and redirections, you name it, were all there, but it is fair to say that it was not easy to manage the life cycle of complex solutions and their features in enterprise-scale projects where developers had to upgrade the solutions over time to meet the ever-changing business requirements. So, unless the developer put a lot of forethought into it, upgrading and uninstalling solutions was not a great story in the earlier versions of SharePoint. SharePoint 2013 changes that with a robust infrastructure to support the upgrade and uninstallation of apps, and to ensure that if an app upgrade fails, it is rolled back, so the hosting SharePoint website isn’t left in an undesirable state without any burden on the side of the developer.

Now that you understand the challenges, it’s time to discuss the improvements.

The New Programming Model

Figure 2 shows the new programming model.

FIGURE 2

In SharePoint 2013 the server-side code runs off the SharePoint server farm via declarative hooks such as apps, declarative workflow, and remote events, which then communicate back to SharePoint using CSOM or REST. In other words, in the new programming model, the emphasis is on client-side code and remote access. Depending on your deployment scenarios , you can still use sandboxed and farm solutions to push server-side code to SharePoint 2013; however, Microsoft recommends that developers follow the new app model as the preferred way of building their custom applications for SharePoint 2013. The message is, “don’t make any new sandboxed solutions” and “build new farm solutions only if you absolutely have to” (and, of course, if your deployment scenario allows you to deploy farm solutions).

In SharePoint 2013, _vti_bin/client.svc is now aliased with _api, which makes it easier to reach out to the service endpoint. Microsoft also made the client.svc and made it a full-blown OData-compliant service.

If you have been working with SharePoint long enough, you probably remember that in SharePoint 2003 you could use Windows SharePoint Services Remote Procedure Call (RPC) protocol to make HTTP GET requests (only HTTP GET) to the OWSSVR.dll ISAPI extension. For example, if you type in the following URL, it exports the schema of a list specified by the GUID and renders it in CAML format:

http://Tailspintoys/sites/marketing/_vti_bin/owssvr.dll?Cmd=ExportList&List= 
e6a9bb54-da25-102b-9a03-2db401e887ec

URLs play an important role in SharePoint. Microsoft has been attempting to make it easier for users to get to SharePoint data for a long time; some of those attempts are still there in the new version (for example, Export to Excel in a list). However, due to restrictions in the design patterns and infamous protocols used in such patterns, the attempts have not been successful. The basic promise behind OData (as the protocol and enabler) and REST (as the design pattern) is to make SharePoint data accessible to just about any other platform and any type of device via URL and standard HTTP verbs.

Figure 3 shows an architectural diagram representing the remote API changes in SharePoint 2013 discussed in this section.

FIGURE 3

To use the new client-side OData service in SharePoint 2013, you construct a RESTful HTTP request against client.svc, which maps to an HTTP verb and corresponds to the CSOM API you want to use. In response, you get an Atom XML (default type) or JavaScript Object Notation (JSON) that can be easily converted to a nested object. The following example demonstrates how you can use REST to query the Contacts list and retrieve an item where the ID equals 1:

http://Tailspintoys.com/_api/web/lists/getByTitle('Contacts')/
getItemByStringId('1')

The following code snippet demonstrates an example of how you can use JavaScript and REST to delete an item from the Contacts list. First, you build a REST URL by concatenating the id parameter passed to the JavaScript function with _spPageContextInfo.webServerRelativeUrl that’s available to you when you use CSOM in JavaScript. Then, you send a request to the SharePoint web server using the jQuery $.ajax function using the HTTP DELETE verb. Finally, you register the callback handlers for success and error operations, and the call is executed asynchronously.

removeItem = function (id) {
        $.ajax(
                {
                    url: _spPageContextInfo.webServerRelativeUrl +
                        "/_api/web/lists/getByTitle('Contacts')/
                        getItemByStringId('" +
                        id + "')",
                    type: "DELETE",
                    headers: {
                        "accept": "application/json",
                        "X-RequestDigest": $("#__REQUESTDIGEST").val(),
                        "IF-MATCH": "*"
                    },
                    success: function (data) {
                        readAll();
                    },
                    error: function (err) {
                        alert(JSON.stringify(err));
                    }
                }
            );
    }

Note in the code snippet how the request headers for the HTTP request were created. The code queries the value of the form digest control on the page with the standard name of __REQUESTDIGEST and adds the value to the X-RequestDigest header. This is important to ensure the HTTP requests that modify the content database can pass the form digest, which is SharePoint’s inherent security check.

Microsoft also extended CSOM to user profiles, workflow, and search, to name a few, and many other workloads that were only available through server-side APIs in SharePoint 2010. But, that’s not all. Microsoft further improved CSOM, so they can support bulk or synchronized operations without causing a significant burden on server performance when SharePoint is used in a production environment with a large user base.

That’s enough abstract talking about apps without discussing what they actually are. In the following section you will enter a new world of extensibility in SharePoint 2013 with apps.